What is the difference between “from traffic-engineering” and “from family traffic-engineering” in a routing policy?

I was asked early this week what the difference between configuring a routing policy matching on “traffic-engineering” and configuring one matching on “family traffic-engineering” is. I found this to be a very good question, so I decided to write a quick note about it.

I agree that seeing these two options for the first time can be puzzling, but the answer is quite simple. However, you know me! I have to give you some context before I go into the specific pieces of information (maybe it is just that I like to talk…); so here it goes:

To get started let’s talk about MP-BGP (Multiprotocol BGP).

MP-BGP enables the advertisement of different protocol families over the same BGP session, regardless of the protocol family used as transport for the session. You could for example, have a BGP session between the IPv4 addresses of two routers, and then advertise both IPv4 routes and IPv6 routes over the same session.

The different families are advertised using the multiprotocol capabilities as defined under RFC 2858:

“To provide backward compatibility, as well as to simplify introduction of the Multiprotocol capabilities into BGP-4 , two new attributes, Multiprotocol Reachable NLRI (MP_REACH_NLRI), and Multiprotocol Unreachable NLRI (MP_UNREACH_NLRI) are used in the MBGP.”

and are identified using the NLRI AFI (Address Family Identifier) and SAFI (Sub-address Family Identifier):

where the values of AFI and SAFI are defined by IANA:

Address Family Numbers

Subsequent Address Family Identifiers (SAFI) Parameters

Example:

AFI=1: IPv4
AFI=2: IPV6
SAFI = 1: unicast routing table only (inet.0)
SAFI = 2: multicast routing table only (inet.2)
SAFI = 3: unicast and multicast routing tables (inet.0 and inet.2)

Using MP-BGP we can for example, have two routers exchanging both IPv4 and IPv6 routes over the same IPv4 BGP session as shown:

In the same way, we can have two routers exchanging both IPv4 routes and traffic engineering routes over the same session:

But what does family traffic engineering mean?

It means we are now in the realm of BGP-LS (BGP Link State), which is defined by:

RFC 7752: North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP

and a router advertising family traffic-engineering routes is sending Link-State NLRIs.

The topic of BGP-LS is extensive, and worth its own article, which I will try to write later, but in essence BGP-LS collects traffic engineering information propagated by the IGP (ISIS or OSPF) and advertises it to a centralized PCE (Path Computation Element) such as Juniper Paragon Pathfinder. This PCE can use the TE information to make intelligent calculations to set up MPLS LSPs, using the Path Computation Element Protocol (PCEP). Another topic for a later discussion.

A router running either ISIS or OSPF (with traffic engineering extensions) maintains one or more databases (LSDB-Link State Database or TED-Traffic Engineering Database) containing link-state information about nodes and links in a given area. This link-state information includes attributes such as local/remote IP addresses, local/remote interface identifiers, link metric and TE metric, link bandwidth, reservable bandwidth, per Class-of-Service (CoS) class reservation state, preemption, and Shared Risk Link Groups (SRLGs).

One or more routers in the area can be configured to peer with the PCE and to extract the information from the LSDB/TED and export it using BGP-LS.

The different pieces of information in the LSDB/TED need to be mapped to BGP NLRIs that describe links, nodes, and prefixes properties and values. This is achieved by encoding the information using Type/Length/Value triplets within MP_REACH_NLRI and MP_UNREACH_NLRI with:

– AFI 16388 / SAFI 71 for BGP-LS,

– AFI 16388 / SAFI 72 for BGP-LS-VPN.

The type identifies the NLRI as:

– Node NLRI (1),

– Link NLRI (2),

– IPv4 Topology Prefix NLRI (3) or

– IPv6 Topology Prefix NLRI (4).

The format for each type varies, but just to give you an idea they will contain attributes such as source protocol (ISIS, OSPF, static, etc), multi-topology ID, OSPF router type, OSPF route type, ISIS level, Autonomous system number, router ID, Area ID, link local/remote IDs, link/local IP addresses, hostname, ISIS system ID, etc.

And now, we can go back to the original question:

what is the difference between configuring a routing policy matching on “traffic-engineering” and configuring one matching on “family traffic-engineering“?

– When you configure a policy matching on family traffic-engineering:

all routes with NLRI/family = traffic engineering will match.

No other route details are needed.